home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-thinosi-cookbook-00.txt < prev    next >
Text File  |  1993-08-09  |  67KB  |  1,596 lines
  1.  
  2.  
  3. Thinosi Working Group                                        P.R.Furniss
  4. INTERNET DRAFT                                                Consultant
  5.                                                              August 1993
  6.  
  7.  
  8.                   Octet sequences for upper-layer OSI
  9.               to support basic communications applications
  10.  
  11. Status of this Memo
  12.  
  13. This draft document is part of the work of the IETF Thinosi Working
  14. Group. It is intended to submit it to the IAB standards track.
  15. Distribution of this memo is unlimited. Comment on this draft should be
  16. sent to the thinosi mailing list: thinosi@ulcc.ac.uk.  Requests to join
  17. this list should be sent to thinosi-request@ulcc.ac.uk.
  18.  
  19. This document is an Internet-Draft.  Internet-Drafts are working
  20. documents of the Internet Engineering Task Force (IETF), its Areas, and
  21. its Working Groups.  Note that other groups may also distribute working
  22. documents as Internet-Drafts.
  23.  
  24. Internet-Drafts are draft documents valid for a maximum of six months.
  25. Internet-Drafts may be updated, replaced, or obsoleted by other
  26. documents at any time.  It is not appropriate to use Internet-Drafts as
  27. reference material or to cite them other than as a "working draft" or
  28. "work in progress."
  29.  
  30. To learn the current status of any Internet-Draft, please check the 1id-
  31. abstracts.txt listing contained in the Internet-Drafts Shadow
  32. Directories on ds.internic.net, ic.nordu.net, ftp.nisc.sri.com, or
  33. munnari.oz.au.
  34.  
  35. Abstract
  36.  
  37. This document specifies those elements of the OSI upper-layer protocols
  38. (Session, Presentation and ACSE) needed to support applications with
  39. "basic communications requirements". These include OSI application
  40. protocols such as X.400 P7 and Directory Access Protocol, and "migrant"
  41. protocols, originally defined for use over other transports.
  42.  
  43. The upper-layer protocol elements are specified in this document as the
  44. particular octet sequences that comprise an "envelope" around the
  45. application protocol's data. It therefore independent, as a document,
  46. from the OSI base standards, although an implementation based on this
  47. document will be able to interwork with an implementation based on the
  48. base standard, when both are being used to support an appropriate
  49. application protocol.
  50.  
  51.  
  52.  
  53.  
  54.  
  55. Expires 11 February 1994                                      [Page 1]
  56.  
  57. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  58.  
  59.  
  60. Table of Contents
  61.  
  62.  1. Introduction ....................................................3
  63.  2. General .........................................................3
  64.   2.1 Subdivisions of "basic communication applications" ............3
  65.   2.2 Conformance and interworking ..................................5
  66.   2.3 Relationship to other documents ...............................6
  67.   2.4 Model of an implementation ....................................6
  68.  3. Contexts and titles .............................................7
  69.   3.1 The concepts of abstract and transfer syntax ..................7
  70.   3.2 Use of presentation context by the cookbook applications ......8
  71.   3.3. Processing Presentation-context-definition-list ..............8
  72.   3.4 Application context ...........................................9
  73.   3.5 APtitles and AEqualifiers .....................................9
  74.  4. What has to be sent and received ...............................11
  75.   4.1. Sequence of OSI protocol data units used ....................11
  76.   4.2. Which OSI fields are used ...................................13
  77.   4.3. Encoding methods and length fields ..........................14
  78.   4.3.1 Session items ..............................................14
  79.   4.3.2 ASN.1/BER items (Presentation and ACSE) ....................15
  80.   4.4. BER Encoding of values for primitive datatypes ..............15
  81.   4.5. Unnecessary constructed encodings ...........................16
  82.  5. Notation .......................................................16
  83.  6. Octet sequences ................................................17
  84.   6.1. Connection request message ..................................17
  85.   6.2. Successful reply to connection setup ........................20
  86.   6.3. Connection rejection ........................................22
  87.   6.4. Data-phase TSDU .............................................22
  88.   6.5. Closedown  - release request ................................24
  89.   6.6. Closedown - release response ................................24
  90.   6.7. Deliberate abort ............................................25
  91.   6.8. Provider abort ..............................................26
  92.   6.9. Abort accept ................................................27
  93.  7. References .....................................................27
  94.  8. Other notes ....................................................28
  95.  9. Author's Address ...............................................28
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112. Expires 11 February 1994                                      [Page 2]
  113.  
  114. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  115.  
  116.  
  117. 1. Introduction
  118.  
  119. The upper-layer protocols of the OSI model are large and complex, mostly
  120. because the protocols they describe are rich in function and options.
  121. However, for support of most applications, only a limited portion of the
  122. function is needed and the protocol elements needed can be expressed
  123. more simply.
  124.  
  125. This memo describes the protocol elements required by the OSI upper
  126. layers when supporting a connection-oriented application with only basic
  127. communication requirements - that is to create a connection, optionally
  128. negotiate the data representation, send/receive data, close a connection
  129. and abort a connection. Optionally, data may be sent on the connection
  130. establishment, closing and abort messages.
  131.  
  132. The protocol elements for the OSI upper layer protocols (i.e. Session ,
  133. Presentation . and Association Control Service Element (ACSE) . needed
  134. to support such an application are a subset of the full protocols
  135. defined in the International Standards ([ISO8326, ISO8327, ISO8822,
  136. ISO8823, ISO8649, ISO8650]). Such a protocol subset can be specified in
  137. a profile, which references the base standards and states which parts
  138. are relevant. Such a profile specification cannot be understood without
  139. reference to the base standards.
  140.  
  141. In this memo, the protocol elements needed are specified in terms of the
  142. octet sequences that comprise the 'envelope' around the application
  143. data. This memo thus provides a re-specification of the relevant parts
  144. of the upper-layer protocols. An implementation based on this memo will
  145. be able to interwork with an implementation based directly on the full
  146. standards when both are supporting a basic communication application.
  147. (The "full" implementation will exhibit only part of its potential
  148. behaviour, since the application will only invoke part).The envelope and
  149. its enclosing data form a Transport Service Data Unit (TSDU) that can be
  150. passed via the OSI Transport Service [ISO8072] (which in turn may be
  151. supported as specified in [RFC1006] or any class of the OSI Transport
  152. Protocol [ISO8073]).
  153.  
  154.  
  155. 2. General
  156.  
  157. 2.1 Subdivisions of "basic communication applications"
  158.  
  159. Distinctions can be made within the "basic communication applications",
  160. as defined above, based on how much use they make of the OSI upper-layer
  161. services. In particular:
  162.  
  163.       a) whether application data is sent on the connection
  164.       establishment, close and abort, or only during "date phase" on an
  165.       established connection;
  166.  
  167.  
  168.  
  169. Expires 11 February 1994                                      [Page 3]
  170.  
  171. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  172.  
  173.  
  174.       b) whether the application data is of only one kind (abstract
  175.       syntax) and one format (transfer syntax) or more than one (i.e.
  176.       how much use is made of the Presentation layer syntax negotiation
  177.       and identification features)
  178.  
  179. These distinctions potentially allow further subsetting, but a large
  180. part of the protocol will be the same. In this memo, four  groups of
  181. supported application are considered, based on these distinctions. All
  182. groups have "basic communications requirements" in requiring only
  183. connection, data transfer and (perhaps) orderly release of
  184. connection.The four groups are:
  185.  
  186.       Group I : applications which send data only on an established
  187.       connection, and use a single abstract and transfer syntax.
  188.  
  189.       Group II : applications which send data on connection
  190.       establishment and release and use a single abstract and transfer
  191.       syntax.
  192.  
  193.       Group III : Applications whose data is in more than one format
  194.       (presentation context) and which need the syntax identification
  195.       and negotiation features of Presentation. Further subdivisions of
  196.       this group are possible
  197.  
  198.       Group III applications that send data of only one kind (one
  199.       abstract syntax) on the connection, but which have more than one
  200.       format (transfer syntax) specified (they use the Presentation
  201.       context negotiation facility)
  202.  
  203.       Group IV applications that will send data of several kinds on the
  204.       connection (and which much therefore distinguish on each write
  205.       which kind is being sent)
  206.  
  207. Group III applications are equivalent to Group I (or possibly Group II)
  208. after the establishment exchange has negotiated the particular transfer
  209. syntax that will be used on the connection.
  210.  
  211. Possible examples of the Groups are:
  212.  
  213.       Group I: application protocols designed for use over transport-
  214.       level protocols. Typically these are non-OSI protocols "migrated"
  215.       to an OSI environment. X Window System protocol is an example.
  216.  
  217.       Group II: Typically OSI-originated protocols with simple
  218.       requirements, including many of the ROSE-based ones, such as
  219.       Directory Access Protocol.
  220.  
  221.       Group III: Protocols that can be treated as Group I, but for
  222.       which more than one encoding of the data is known, such as a
  223.       standardised one and a system-specific one - all implementations
  224.  
  225.  
  226. Expires 11 February 1994                                      [Page 4]
  227.  
  228. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  229.  
  230.  
  231.       understand the standard encoding, but Presentation layer
  232.       negotiation allows like-implementations to use their internal
  233.       encoding for transfer, without loss of general interworking. The
  234.       same could apply to OSI protocols.
  235.  
  236.       Group IV: OSI protocols with multiple abstract syntaxes but where
  237.       each message is from a single abstract syntax, and that do not
  238.       use any of the special Session functional units - X.400 P7 is an
  239.       example.
  240.  
  241. Some of the OSI protocols that are not included are those that use more
  242. than one abstract syntax in a single message (such as FTAM or
  243. Transaction Processing) or use Session functional units (RTSE-based
  244. protocols, Virtual Terminal).
  245.  
  246. 2.2 Conformance and interworking
  247.  
  248. The protocol elements specified in this memo correspond to the kernel
  249. functional units of Session, Presentation and ACSE, and the duplex
  250. functional unit of Session.
  251.  
  252. The octet sequences given below are derived from the specifications in
  253. the International Standards for the protocols Session [ISO8327],
  254. Presentation [ISO8822] and ACSE [ISO8650]. The intention of this memo is
  255. to summarise those specifications, as applicable to the supported
  256. application groups, so that an implementation could be developed without
  257. direct reference to the original standards, but capable of interworking
  258. with implementations that had made direct reference. The OSI standards
  259. (especially Presentation) allow considerable flexibility in the encoding
  260. of the protocol data units. Accordingly, this memo defines particular
  261. octet sequences to be sent, and describes the variations that can be
  262. expected in data received from an implementation based directly on the
  263. OSI standards, rather than on this cookbook. It is intended that an
  264. implementation that sends these sequences and that is capable of
  265. interpreting the variations described will be fully able to interwork
  266. with an implementation based directly on the OSI standards. An
  267. implementation that is only capable of interpreting the octet sequences
  268. specified in this memo for transmission may not be able to interwork
  269. with standards-based implementations.
  270.  
  271. The intent is to be able to interwork with conformant implementations in
  272. support of the relevant application (or group of applications). Some of
  273. the OSI standards have conformance requirements that go beyond that
  274. necessary for successful interworking, including detection of invalid
  275. protocol. Tests for conformance sometimes go beyond the strict
  276. conformance requirements of the standard. Consequently an implementation
  277. based on this memo may or may not be able to formally claim conformance
  278. to the International Standard. It may be able to legitimately claim
  279. conformance, but fail a conformance test, if the test is over-specified.
  280.  
  281.  
  282.  
  283. Expires 11 February 1994                                      [Page 5]
  284.  
  285. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  286.  
  287.  
  288. (Efforts are being made to correct this, but in the meantime, the target
  289. is interworking with conformant implementations)
  290.  
  291. 2.3 Relationship to other documents
  292.  
  293. The flexibility allowed in the Session, Presentation and ACSE standards
  294. is restricted in the Common Upper-Layer Requirements Part 1 [CULR-1] ).
  295. This is a proposed International Standardised Profile (pdISP 11188-1)
  296. that can be assumed to be obeyed by most implementations. This memo
  297. applies the restrictions of CULR-1, especially where these concern
  298. maximum sizes of fields and the like.Points where advantage is taken of
  299. a CULR-1 limitation are noted.
  300.  
  301. Additional parts of CULR are under development. Part 3 [CULR-3] covers
  302. the protocol elements needed for "basic communications applications",
  303. and is being developed in (informal) liaison with this memo. CULR-3 is
  304. presented as a normal profile, largely consisting of prescribed answers
  305. to the questions in the PICS (Protocol Implementation Conformance
  306. Statement) of the three protocols.CULR-3 does not make the distinction
  307. between the four Groups.An implementation of this memo (at least if it
  308. supported Group IV) would be able to claim conformance to CULR-3, with
  309. the possible exception of any more-than-interworking conformance
  310. requirements inherited by CULR-3 from the base standards.
  311.  
  312. An extension [XTI/mOSI] to the X/Open Transport Interface [XTI] is
  313. shortly to be published as a preliminary specification. This defines an
  314. API to the OSI upper-layers, again as appropriate to a basic
  315. communications application. XTI/mOSI would be usable as an interface to
  316. support applications in groups I, II and III, and possibly group IV.
  317.  
  318. 2.4 Model of an implementation
  319.  
  320. This memo does not require any particular structuring of the
  321. implementation. An implementation could be developed to support all the
  322. groups, or only some of the simpler groups, or a specific application.
  323. Nevertheless, the memo defines the protocol to be created and
  324. interpreted by a notional component that has
  325.  
  326.    an upper boundary  to an application that passes to it and receives
  327.    from it requests for connection, disconnection and sequences of
  328.    application data. Any internal structure in the application data is
  329.    transparent to the component.
  330.  
  331.    a lower boundary  to the OSI Transport layer, to and from which the
  332.    component passes requests for transport connection and disconnection,
  333.    and Transport Service Data Units to be sent/received on the T-DATA
  334.    service.
  335.  
  336. For a general implementation, the upper boundary (interface) will need
  337. to distinguish whether the application data is a "single-ASN.1-type"
  338.  
  339.  
  340. Expires 11 February 1994                                      [Page 6]
  341.  
  342. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  343.  
  344.  
  345. encoded with the Basic Encoding Rules, or a  non-ASN.1/BER octet
  346. string(because it changes one octet in the envelope). For group
  347. iVapplications it will be necessary to distinguish which syntax the
  348. particular data item is in.
  349.  
  350.  
  351. 3. Contexts and titles
  352.  
  353. 3.1 The concepts of abstract and transfer syntax
  354.  
  355. OSI includes the concepts of "abstract syntax" and "transfer syntax".
  356. These are terms for the content (abstract syntax) and format "on-the-
  357. line" (transfer syntax) of the protocol elements. The combination of an
  358. abstract syntax and transfer syntax is called a presentation context.
  359.  
  360. Application protocols devised explictly under OSI auspices have used
  361. ASN.1 for the definition of the abstract syntax, and nearly all use the
  362. Basic Encoding Rules applied to the ASN.1 to define the transfer syntax.
  363. However, there is no such requirement in OSI in general or in OSI
  364. Presentation, and still less is there any requirement to change the
  365. representation of existing application protocols to ASN.1 (for their
  366. definition) or BER (for their transmission). It is not generally
  367. realised (even in OSI circles) that all communicating applications, in
  368. all environments, are using some form of these, although under different
  369. names and without the explicit identification that the OSI Presentation
  370. provides. OSI thus separates the identification of the content and
  371. format of the data from the addressing.
  372.  
  373. Formal specifications of non-OSI application protocols (such as TELNET,
  374. FTP, X Windows System) generally do not use ASN.1, but will invariably
  375. be found to define abstract and transfer syntaxes.  For a less
  376. formalised protocol used between similar systems, the abstract syntax
  377. may be defined simply in programming language structures, and the
  378. transfer syntax determined by an available compiler represents this in
  379. memory.
  380.  
  381. The OSI Presentation protocol requires that "names" be assigned to the
  382. abstract and transfer syntaxes of the application data that is carried.
  383. The names are always object identifiers (oids): globally unique names
  384. assigned hierarchically. Presentation supports the negotiation of a
  385. transfer syntax for a particular abstract syntax - several can be
  386. offered and one selected.
  387.  
  388. This transfer syntax negotiation facility may be especially useful for
  389. non-ASN.1 syntaxes where there is more than one representation available
  390. (perhaps differing in byte-ordering or character code). In such a case,
  391. on the connection establishment, all of the transfer syntaxes supported
  392. by the initiatior are offered, and any one of these accepted by the
  393. responder, at its own choice. If the two systems share some "native"
  394. format they can negotiate that, avoiding transformation into and out of
  395.  
  396.  
  397. Expires 11 February 1994                                      [Page 7]
  398.  
  399. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  400.  
  401.  
  402. the more general format. Following the negotiation, the application can
  403. be regarded as if it were group I. The same applies to an ASN.1-defined
  404. abstract syntax, but in practice non-BER encodings of ASN.1 are rare.
  405. (An ASN.1-defined abstract syntax could be treated as a Group III
  406. application offering the BER transfer syntax and some implementation-
  407. specific representation as alternatives - if the responder is the same
  408. implementation, an efficiency gain is possible.)
  409.  
  410. 3.2 Use of presentation context by the cookbook applications
  411.  
  412. For an application where the application data can be treated (by this
  413. component ) as an unstructured stream of bytes, there will be a "real"
  414. abstract syntax and transfer syntax, but these will be understood and
  415. processed by the "application". For such application protocols  there is
  416. no need to identify the  abstract and transfer syntaxes being used -
  417. they are known by some other means (effectively inferred from the
  418. addressing).  A generic (anonymous, if you like) name for both syntaxes
  419. can be used. However, in some cases object identifier names will be
  420. assigned for the syntaxes of the application protocol. In these cases,
  421. it will be appropriate to use them. It would even be legitimate to offer
  422. both the generic and specific names, with the responder accepting the
  423. specific (if it knew it) and the generic if the specific were not known
  424. - this will provide a migration option if names are assigned to the
  425. syntaxes after implementations are deployed using the generic names.
  426. CULR-3 defines object identifiers for "anonymous"  abstract and transfer
  427. syntax names (currently called "default", but this is expected to
  428. change).
  429.  
  430. For abstract syntaxes defined in ASN.1 object identifier names will have
  431. been assigned to the abstract syntax with the specification. This name
  432. MUST be used to identify the abstract syntax. The transfer syntax will
  433. most often be the Basic Encoding Rules (BER) object id, but alternatives
  434. (e.g. Packed Encoding Rules) are possible..
  435.  
  436. For group III and group IV applications, specific object identifier
  437. names must be used for all the abstract and transfer syntaxes. If these
  438. names are not assigned with the specification (e.g. if the specification
  439. not in ASN.1) they can be assigned by whoever needs them --- ideally the
  440. "owner" of the syntax specification.
  441.  
  442. 3.3. Processing Presentation-context-definition-list
  443.  
  444. In Presentation context negotiation on connection establishment the
  445. initiator sends a list (the presentation context definition list) of the
  446. abstract syntaxes it intends to use, each with a list of transfer
  447. syntaxes. Each presentation context also has an integer identifier. To
  448. build the reply, a responder has to examine this list and work out which
  449. of the offered presentation contexts will be accepted and which (single)
  450. transfer syntax for each. The responder sends back the reply field, the
  451. Presentation-context-definition-result-list, in the accept message. The
  452.  
  453.  
  454. Expires 11 February 1994                                      [Page 8]
  455.  
  456. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  457.  
  458.  
  459. result list contains the same number of result items as the definition-
  460. list proposed presentation-contexts. They are matched by position, not
  461. by the identifiers (which are not present in the result-list). An
  462. acceptance also includes the transfer syntax accepted (as there can be
  463. several offered). This can be copied from the definition list.
  464.  
  465. For the group I, group II and group III cases,  only the ACSE and one
  466. application-data P-context will be used and all other contexts rejected.
  467. For the group IV case, several presentation contexts will be accepted.
  468.  
  469. However, even for group I applications there may be synonyms for an
  470. application-data Presentation-context. Unknown synonyms are rejected.
  471. The reply shown in 6.2 includes a rejection (It can therefore not be the
  472. reply to the connection request shown in 6.1, since that has only two
  473. items in the definition list.)
  474.  
  475. In all cases, the connection responder must identify and keep the
  476. presentation context identifiiers (called pcid's here) for all the
  477. accepted presentation contexts. These are integers (odd integers, in
  478. this case). CULR-1 limits them to no greater than 32767, but they will
  479. probably usually be <= 255 (so taking up one octet).
  480.  
  481. A presentation context is sometimes used (i.e. data is sent using it)
  482. before the negotiation is complete. As will be seen in section 6, in
  483. these cases, the transfer syntax name sometimes appears with the integer
  484. identifier.
  485.  
  486. 3.4 Application context
  487.  
  488. The Association Control Service Element also exchanges the name (another
  489. Object Identifier) of the application context, which identifies what the
  490. communication is all about, again independently of the naming and
  491. addressing.  As for the syntaxes, although some name must be present in
  492. the protocol, a generic name can be used for applications that do not
  493. have a specific name assigned. (This will almost certainly be a group I
  494. application - if a specific name is assigned, it MUST be used.). The
  495. only negotiation allowed is that the reply may be different from that
  496. sent by the initiator. CULR-3 provides a generic application context
  497. name (i.e. assigns an object identifier).
  498.  
  499. 3.5 APtitles and AEqualifiers
  500.  
  501. In addition to the addressing constructs (transport address and possibly
  502. session and presentation selectors), the communicating application
  503. entities have names - Application-Entity titles (AEtitle). These are
  504. carried by ACSE as two fields -the Application-process titles (APtitle)
  505. and the Application-entity qualifier (AEqualifier). The AEtitle is
  506. compound, and the APtitle consists of all but the last element, which is
  507. the AEqualifier. (This explanation can be run backwards). There are two
  508. non-equivalent forms. AP-titles and AE-titles can be Directory Name or
  509.  
  510.  
  511. Expires 11 February 1994                                      [Page 9]
  512.  
  513. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  514.  
  515.  
  516. an Object Identifier. AE-qualifiers can be Relative Distinguished Name
  517. (RDN) or an integer - the forms must match, since the AE-qualifier is
  518. the last component of the AP-title. In practice, the Directory form is
  519. likely to be the only one seen for a while.
  520.  
  521. Use of the these names is rather variable. This cookbook proposes that
  522. implementations should be able to handle any value for the partner's
  523. names, and set (as initiator) its own names. This is primarily to
  524. facilitate OSI:non-OSI relaying (e.g. X/osi:X/tcp), allowing the names
  525. of the end-system to be carried to the relay, where they can be
  526. converted into hostnames, and the lower-layer address determined. OSI
  527. assumes that name-to-address lookup is possible (via the Directory or
  528. other means), but does not assume address-to-name will work. Thus the
  529. calling AE-title is needed if the responder is to know who the initiator
  530. is. However, most protocols work perfectly well without these names
  531. being included.
  532.  
  533. As for their encoding, a RDN will almost always be a single attribute
  534. value assertion, with the attribute defined either by the Directory
  535. standard [ISO9594 = X.500], or in [Internet/Cosine Schema][RFC1274].
  536. Using the notation defined below, the encoding of an RDN using a
  537. Directory-defined standard attribute is:
  538.  
  539. 31  80  {1         - RDN, [SET OF]
  540. 30  80  {2         - AttributeValueAssertion, [SEQUENCE]
  541. 06  03  5504yy     -- OID identifying an attribute named in
  542.                    -- the Directory standard
  543.                    -- which one is determined by yy
  544. 13  La  xxxxxx     -- [Printable string]
  545.                    -- could be T61 string, with tag 14
  546. 00  00  }2         - end of AVA
  547. 00  00  }1         - end of RDN
  548.  
  549. The most likely attributes for an RDN have the following hex values for
  550. yy
  551.  
  552.      CommonName               03
  553.      Country                  06
  554.      Locality                 07
  555.      State/Province           08
  556.      Organisation             0A
  557.      OrganisationUnit         0B
  558.  
  559. For non-Directory attributes, the object id name must be substituted
  560. (thus changing the immediately preceeding length)
  561.  
  562. If there are multiple attribute value assertions in the RDN, the group
  563. between {2 and 2} is repeated (with different attributes). Order is not
  564. significant.
  565.  
  566.  
  567.  
  568. Expires 11 February 1994                                     [Page 10]
  569.  
  570. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  571.  
  572.  
  573. The encoding of a [Directory] Name for the AP-titles is the RDNs (high-
  574. order first) within
  575.  
  576. 30  80  {1        - [SEQUENCE] Name
  577.  -- put the RDN encodings here
  578. 00  00  }1
  579.  
  580. An Object Identifier AP-title is encoded as a primitive (see below),
  581. with the "universal" tag for an object identifier, which is 6. The
  582. integer AE-qualifer uses the universal tag for an integer, which is 2.
  583.  
  584.  
  585. 4. What has to be sent and received
  586.  
  587. 4.1. Sequence of OSI protocol data units used
  588.  
  589. OSI defines its facilities in terms of services but these are abstract
  590. constructs (they do not have to correspond to procedure calls) - the
  591. significant thing is the transmission of the resulting  protocol data
  592. unit (PDU). The PDU at each layer carries (as user data) the PDU of the
  593. layer above. The different layers follow different conventions for
  594. naming the pdus. This section gives an overview of the sequence of PDUs
  595. exchanged - the details of these are given in section 6.
  596.  
  597. The requirements of the application are to create a connection(strictly
  598. an association for the application-layer in OSI, but called a connection
  599. here), to send and receive data and to close the connection.  The PDUs
  600. used are thus:
  601.  
  602. To create connection :
  603.  
  604.         First create transport-level connection
  605.  
  606.         Initiator sends the message defined in 6.1, which is Session
  607.         CONNECT carrying Presentation CONNECT request [CP] carrying
  608.         ACSE A-ASSOCIATE request [AARQ] optionally carrying application
  609.         data.
  610.  
  611.         Responder replies with the message defined in 6.2, which is
  612.         Session ACCEPT carrying Presentation CONNECT response [CPA]
  613.         carrying ACSE response [AARE] optionally carrying application
  614.         data.
  615.  
  616.      -  If the responder rejects the attempt, the reply will be Session
  617.         REJECT. This is defined in 6.3, where the REJECT carries no
  618.         user data. A received REJECT may carry Presentation, ACSE and
  619.         application data, although 6.3 shows only how to reject at
  620.         Session level..
  621.  
  622. To send/receive data on an connection
  623.  
  624.  
  625. Expires 11 February 1994                                     [Page 11]
  626.  
  627. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  628.  
  629.  
  630.         send the message defined in 6.4, which is an empty Session
  631.         GIVE-TOKEN followed by Session S-DATA carrying Presentation P-
  632.         DATA [TD] containing the application data (The GIVE-TOKEN is
  633.         just two octets required by Session for some backwards
  634.         compatibility)
  635.  
  636. To close connection gracefully
  637.  
  638.         One side sends the message defined in 6.5, which is Session
  639.         FINISH carrying P-RELEASE request carrying A-RELEASE request
  640.         [RLRQ] optionally carrying application data (This side may now
  641.         receive, but not send data)
  642.  
  643.         The other side replies with the message defined in 6.6, which
  644.         is Session DISCONNECT carrying P-RELEASE response carrying A-
  645.         RELEASE response [RLRE] optionally carrying application data
  646.  
  647.         First side disconnects transport connection on receiving the
  648.         reply
  649.  
  650. To close connection abruptly but also send application data
  651.  
  652.         Send the message defined in 6.7, which is Session ABORT
  653.         carrying Presentation U-ABORT [ARU] carry ACSE U-ABORT [ABRT]
  654.         carrying application data (delivery not guaranteed)
  655.  
  656.         On receiving Session ABORT, disconnect transport
  657.  
  658. To close connection abruptly
  659.  
  660.      -  Either sent the message defined in 6.8, which is Session ABORT
  661.         carrying nothing;
  662.  
  663.         Or, just disconnect at transport level
  664.  
  665. A group I application is assumed (by definition) not to send data on the
  666. establishment and release exchanges, a group II application will.
  667.  
  668. It would be possible to use the abort-with-data facility with a group I
  669. to send a (possibly non-standardised) error message for diagnostic
  670. purposes.
  671.  
  672. A special rule is used if a release collision occurs (i.e. FINISH+P-
  673. RELEASE+RLRQ received after sending the same): the side that initiated
  674. the original upper-layer connection waits and the other side replies
  675. with the DISCONNECT etc.
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682. Expires 11 February 1994                                     [Page 12]
  683.  
  684. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  685.  
  686.  
  687. 4.2. Which OSI fields are used
  688.  
  689. There are a number of fields (parameters) in the pdus involved. These
  690. can be categorised by how much support must be provided by a cookbook
  691. implementation - a field may  be "useful", "send-only", "fixed", "fixed
  692. with default", "internal" or "not important". Even those that are not
  693. important may be received from another implementation, but since the
  694. application has no use for them, they can be ignored.
  695.  
  696. The text below describes the processing that is required for each
  697. category and which fields are in each category.
  698.  
  699. "Useful" - when sending, the implementation SHOULD be able to set any
  700. (legal) value of these fields (via the upper interface from the
  701. application or via some configuration or lookup mechanism) and SHOULD
  702. pass received values for the Calling values to the application (for
  703. specific applications, these fields may be either required or
  704. unnecessary.).
  705.  
  706.     AARQ:
  707.  
  708.       Called application-process title
  709.       Called application-entity qualifier
  710.       Calling application-process title
  711.       Calling application-entity qualifier
  712.  
  713. "Send-only" - the implementation must be able to set any value of these,
  714. but can ignore any received value. Both are octet strings.
  715.  
  716.       Presentation selector (up to 4 octets, limited by CULR-1)
  717.       Session selector (up to 16 octets, limited by base standard)
  718.  
  719.  
  720. "Fixed" (constant for all applications)
  721.  
  722.       abstract and transfer syntax identifiers for presentation context
  723.       for ACSE
  724.       Version numbers - 2 for session, 1 for Presentation and ACSE
  725.  
  726.  
  727. "Fixed with default" - the value is specific to the application. For
  728. non-ASN.1 abstract syntaxes (group I or group II only) applications, the
  729. anonymous values assigned by the OIW minimal OSI profile [CULR-3] can be
  730. used. The CULR-3 default application context can be used where a proper
  731. context name is neither available nor needed.
  732.  
  733.       Application context
  734.                        CULR-3  default is {1 0 11188 3 3}
  735.       Abstract syntax identifier for application data
  736.                        CULR-3 anonymous name is {1 0 11188 3 1 1}
  737.  
  738.  
  739. Expires 11 February 1994                                     [Page 13]
  740.  
  741. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  742.  
  743.  
  744.       Transfer syntax identifier for application data
  745.                        CULR-3 anonymous name is {1 0 11188 3 2 1}
  746.  
  747.  
  748. "Internal" - an arbitrary value can be sent; a received value must be
  749. stored for use in sending.
  750.  
  751.       Presentation context identifiers for ACSE and the application data
  752.       (always odd integers)
  753.  
  754. "Not important" - any legal received value for the other fields MUST be
  755. received (i.e. the pdu is parsed successfully), but can then be ignored.
  756. There is no requirement (in this cookbook) to check the existence, value
  757. or internal format of these fields.
  758.  
  759.       All other fields (which includes a large number of session fields)
  760.  
  761. 4.3. Encoding methods and length fields
  762.  
  763. Both Session and ASN.1/BER [ISO8824, ISO8825] use a type-length-value
  764. structure for their encodings, but different ones. Presentation protocol
  765. and ACSE protocol use the ASN.1/BER encoding and consequently a
  766. Presentation PDU containing an ACSE PDU can be constructed or parsed as
  767. if it were a single structure.
  768.  
  769. All the protocols contain pdu fields with a compound structure. If one
  770. of these is being ignored it may be necessary (for BER, not session) to
  771. determine the lengths of its components to find the length of the
  772. ignored field.
  773.  
  774. Many of the lengths in the specification below will vary, dependent on
  775. the values of the fields.
  776.  
  777. 4.3.1 Session items
  778.  
  779. The type field of a session item is always a single octet.
  780.  
  781. For session items, given a particular length, there is no flexibility:
  782.  
  783.       If the length is less than 255, represent as one octet
  784.  
  785.       If the length is greater, represent as three octets, first is
  786.       0xFF, next two are the length, high-order octet first.
  787.  
  788. (Some "real" implementations are known to use the second encoding in all
  789. cases. This is wrong, but should only concern conformance testers.)
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796. Expires 11 February 1994                                     [Page 14]
  797.  
  798. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  799.  
  800.  
  801. 4.3.2 ASN.1/BER items (Presentation and ACSE)
  802.  
  803. The type field for ASN.1-BER is the tag. Although it is possible for
  804. large tags (>30) to be multi-octet, there are no large tags in the
  805. protocols involved in this memo. Bit 6 (0x20) of the tag octet is 1 if
  806. the item is constructed (i.e. the value is itself one or more ASN.1 BER
  807. items) or 0 if it is primitive.
  808.  
  809. There is considerable flexibility, at senders option, in how lengths are
  810. represented in BER. There are three forms: short, long and indefinite.
  811.  
  812.       Short (usable only if the length is less than 127) : one octet
  813.  
  814.       Long (usable for *any* length) : first octet has the top bit set,
  815.       the rest is a count of how many octets are holding the length
  816.       value; that many subsequent octets hold the length. A long length
  817.       may use more than the minimum number of octets (so 0x8400000001 is
  818.       a valid representation of length 1)
  819.  
  820.       Indefinite (usable only for the length of a compound field) : the
  821.       single octet is 0x80, then one or more items (their tag-length-
  822.       values) and finally two octets of 0x00 (equivalent to tag and
  823.       length of zero).
  824.  
  825. To be able to interwork generally, an implementation must be able to
  826. handle any of these forms when receiving.
  827.  
  828. The encodings specified in the octet sequences below use indefinite
  829. length for all constructed items. This slightly increases the number of
  830. octets sent, but means that the length of a varying field (e.g. user
  831. data, or a varying object identifier) affects only the length of the
  832. item itself, and not the enclosing lengths. It is thus possible to use
  833. the octet sequences as templates interspersed by the varying fields.
  834.  
  835. 4.4. BER Encoding of values for primitive datatypes
  836.  
  837. The following ASN.1 primitive datatypes are used in the thinosi stack..
  838.  
  839. Integers are encoded in twos-complement, high-order first. Unlike
  840. lengths, they must be encoded in the minimum number of octets (no
  841. leading 00 padding).
  842.  
  843. Object Identifiers have a rather peculiar, but compressed encoding:
  844.  
  845.       Combine the first two integers of the OID into one element by
  846.       multiplying the first (always 0, 1 or 2) by 40, and add the
  847.       second.
  848.  
  849.       Each element (that one, and each subsequent integer in the OID
  850.       taken on its own), is a taken as a binary number and divided into
  851.  
  852.  
  853. Expires 11 February 1994                                     [Page 15]
  854.  
  855. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  856.  
  857.  
  858.       7-bit "bytes". This is apportioned into bits 1-7 of the minimum
  859.       number of octets. Bit 8 is one for all octets of the sequence
  860.       except the last. (This means that elements of less than 127 are
  861.       single octet integers.)
  862.  
  863. Printable Strings - as if in ISO 646 (ASCII)
  864.  
  865. OCTET STRING - just put the octets there
  866.  
  867. 4.5. Unnecessary constructed encodings
  868.  
  869. BER allows the sender to break some items (such as OCTET STRINGS,
  870. character strings) into several pieces (i.e. as constructed encoding) or
  871. send them as primitive. CULR-1 requires that this is only done to one
  872. level. The pieces of both OCTET STRING and character string are tagged
  873. as if they were OCTET STRING - they have the tag 04. This memo does not
  874. include any of these optional constructions, but they may be received in
  875. interworking.
  876.  
  877.  
  878. 5. Notation
  879.  
  880. The constructs are shown in their tag - length - value form. All numbers
  881. are in hexadecimal. Comments are preceded by a '-' character. Multiple
  882. '-' mean the comment is more than just information.
  883.  
  884. The tag column contains one of:
  885.  
  886.       single fixed octets.
  887.  
  888.       * in the tag field indicates one or more pdu fields (possibly
  889.       constructed) that may be received but are not sent. If received
  890.       they can be ignored.
  891.  
  892.       ! indicates the tag is defined elsewhere.
  893.  
  894.       .  is a place holder for the column.
  895.  
  896.       ? preceding the tag value indicates that the field is not always
  897.       present - the comment will explain.
  898.  
  899. The length column contains one of
  900.  
  901.       explicit value
  902.  
  903.       Ls - a length according to session rules which depends on the
  904.       total size of the value (usually constructed)
  905.  
  906.       La - a length according to BER rules
  907.  
  908.  
  909.  
  910. Expires 11 February 1994                                     [Page 16]
  911.  
  912. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  913.  
  914.  
  915.       . is a placeholder
  916.  
  917.       yy is exactly one octet (i.e. one hex digit per y) holding part of
  918.       the length
  919.  
  920. The value column contains one of
  921.  
  922.       the hex value
  923.  
  924.       xxxxxx - value of varying length (sometimes constructed)
  925.  
  926.       {n - (n = number) the start of a constructed value
  927.  
  928.       n - (n=number) the end of the constructed value with the
  929.       corresponding number. (The number is sometimes omitted on the
  930.       innermost nest of construction)
  931.  
  932.       yy - as part of a value - a variable value, each y represents one
  933.       hex digit
  934.  
  935.       ? a value, possibly constructed that may be received but is not
  936.       sent. It may be ignored if received
  937.  
  938. Note that all presentation lengths may be received in one of the
  939. alternative forms. All constructed lengths are shown in indefinite form.
  940. If a received length is definite, the corresponding end item (which will
  941. be shown here as 00 00 }n)  will become  . . }n.
  942.  
  943. In the comments, the notation {n} refers to the constructed item
  944. bracketed by the {n, }n fields.
  945.  
  946.  
  947. 6. Octet sequences
  948.  
  949. 6.1. Connection request message
  950.  
  951.      - CONNECT SPDU
  952. 0D  Ls  {1       - "SI" value for CONNECT = 13
  953. *   Ls  ?        - Connection Identifier
  954. 05  06  {2       - Connect/Accept Item
  955. 13  01  00       - protocol options (probably mandatory)
  956. *   Ls  ?
  957. 16  01  02       -- version number (bottom bit = v1, next bit =v2.
  958.                  --     may get offers of either or both
  959. *   Ls  ?
  960. .   .   }2       - End Connect/Accept Item
  961. 14  02  0002     - Session User Requirements (functional units)
  962.                  - Id (20), length (always 2), duplex fu only.
  963.                  -- On receipt, other bits may be set
  964.                  -- check that the 2 bit is set
  965.  
  966.  
  967. Expires 11 February 1994                                     [Page 17]
  968.  
  969. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  970.  
  971.  
  972. *   Ls  ?        - we do not send any Calling Session Selector
  973. ?34 Ls  xxxx     -- Called Session Selector (i.e. the other end's)
  974.                  -- up to 16 octets - you must set what the other side
  975.                  -- demands.  - May be anything characters, binary etc.
  976.                  -  {3} disappeared in editing
  977. C1  Ls  {4       -- User Data, Identifier=193. if length is > 512,
  978.                  -- then identifier is 194 (hex C2) instead
  979. - CP - P-CONNECT-RI PPDU. Everything below is in ASN.1 BER
  980. 31  80  {5       - [SET]
  981.            --- Mode-selector (the {6} group) could possibly
  982.            --- come after everything else {7}
  983.            --- This will probably only be done by
  984.            --- evil-minded conformance testers
  985. A0  80  {6       - Mode-selector [0] IMPLICIT SET
  986. 80  01  01       - [0] IMPLICIT INTEGER {normalmode(1)}
  987. 00  00  }6
  988. A2  La  {7       - [2] unnamed IMPLICIT SEQUENCE
  989. *   La  ?
  990. ?82 La  xxxx     - [2] Called-presentation-selector
  991.                  - CULR says maximum length is 4
  992.                  -- must be what the other side wants
  993. A4  80  {8       - [4] Presentation-context-definition-list
  994.              ---  items (the outer SEQUENCEs) within the {8} list may
  995.              ---  be in any order.
  996. 30  80  {9       - [SEQUENCE]
  997. 02  01  01       -- Defines pcid for ACSE; received value will be
  998.                  -- a one or two octet odd integer
  999. 06  04  52010001 - [OID] for ACSE abstract syntax
  1000. 30  80  {        - [SEQUENCE]
  1001. 06  02  5101     - [OID] Transfer syntax name is BER
  1002. 00  00  }        - end t-s list
  1003. 00  00  }9       - end acse pctx defn
  1004. 30  80  {10      - [SEQUENCE]
  1005. 02  01  03       -- [INTEGER] Defines pcid for application data;
  1006.                  -- received value will be a one or two octet odd
  1007.                  -- integer
  1008. 06  La  xxxxxx   - [OID] object identifier name of application abstract
  1009.                  -  syntax (if CULR-3 default is used, this line is
  1010.                  -  06  06  28CC64030101)
  1011. 30  80  {11
  1012. 06  La  xxxxxx   - [OID] t-s name for application data
  1013.                  - (if CULR-3 default is used, this line is
  1014.                  -  06  06  28CC64030201)
  1015.              -- will be several of these if multiple t-s offered
  1016.              -- (application is Group III)
  1017.              -- all will have the same tag 06
  1018. 00  00  }11      - end transfer syntax list for application p-ctx
  1019. 00  00  }10       - end application pctx definition
  1020.              -- if multiple presentation contexts are offered, (Group
  1021.              -- IV), the {10} SEQUENCE will repeat appropriately
  1022.  
  1023.  
  1024. Expires 11 February 1994                                     [Page 18]
  1025.  
  1026. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  1027.  
  1028.  
  1029.              -- if multiple contexts are to be accepted, all the pcid's
  1030.              -- must be remembered
  1031. 00  00  }8       - end of p-ctx-def-list
  1032. *   La  ?
  1033. 61  80  {12      - [APPLICATION 1] User-data - Fully-encoded
  1034. 30  80  {13      - [SEQUENCE] PDV-list
  1035. 02  01  01      -- [INTEGER], value is acse pcid
  1036. A0  80  {14      - [0] Single-ASN1
  1037. - ACSE A-ASSOCIATE request APDU - AARQ
  1038. 60  80  {15      - [APPLICATION 0] - AARQ
  1039. *   La  ?        -  protocol version defaults to 1 (only one defined)
  1040. A1  80  {        - [1] Application-context
  1041. 06  La  xxxxxx   -- object identifier name of application context
  1042.                  - (if CULR-3 default is used, this line is
  1043.                  -  06  05  28CC640303)
  1044. 00  00  }
  1045.           -- Called application process title {16} and application
  1046.           -- entity qualifier may or may not be needed (see 3.4)
  1047. ?A2 80  {16      - [2] Called Application-Process title
  1048. ?!  La  xxxxxx   -- see 3.5 - either a Directory Name or an oid
  1049. ?00 00  }16      - end Called APtitle
  1050. ?A3 80  {17      - [3] Called Application-Entity Qualifier
  1051. ?!  La  xxxxxx   -- see 3.5
  1052. ?00 00  }17
  1053. *   La  ?
  1054.           Calling AP-title and AE-qualifier may or may not be needed.
  1055. ?A6 80  {18      - [6] Calling Application-Process title
  1056. ?!  La  xxxxxx   -- see 3.5
  1057. ?00 00  }18
  1058. ?A7 80  {19      - [7] Calling Application-Entity Qualifier
  1059. ?!  La  xxxxxx   -- see 3.5
  1060. ?00 00  }19
  1061. *   La  ?
  1062.          -- the user information field may or may not be required
  1063.          -- (not required for Group I)
  1064. ?BE 80  {20      - [30] IMPLICIT SEQUENCE
  1065. ?08 80  {21      - [EXTERNAL]
  1066. ??06 La xxxxxx   -- [OID] This is the oid identifying the transfer
  1067.                  -- syntax used for the user data.
  1068.                  -- It is (almost certainly) required even if only
  1069.                  -- one transfer syntax was proposed.
  1070. ?02 01  03       -  [INTEGER] this is the pcid for the application data
  1071. ?A0 La  xxxxxx   -- [0] single-ASN.1-type - the application data
  1072.                  --      (see paragraph at end of this section below}
  1073. ?00 00  }21      - end of EXTERNAL
  1074.          -- conceivably there may be several EXTERNALS, probably in
  1075.          -- different presentation contexts (different pcids)
  1076. ?00 00  }20      - end of user information field
  1077. 00  00  }15      - end of AARQ
  1078. 00  00  }14      - end of single-ASN-type
  1079.  
  1080.  
  1081. Expires 11 February 1994                                     [Page 19]
  1082.  
  1083. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  1084.  
  1085.  
  1086. 00  00  }13      - end of PDV-list
  1087. 00  00  }12      - end of Presentation User-data
  1088. 00  00  }7       - end of third element of CP-type SET
  1089. 00  00  }5       - end of CP-type
  1090. .   .   }4       - end of session user data
  1091. .   .   }1       - end of CONNECT SPDU
  1092.  
  1093. The application data carried in the EXTERNAL is shown (as A0 La xxxx)
  1094. assuming it is a single-ASN.1 type, which it often will be for group II
  1095. (since these tend to be OSI applications). The xxxx will be the BER
  1096. encoding of the application pdu (probably something like Z-BIND or Y-
  1097. INITIALIZE). The length may be indefinite.
  1098.  
  1099. If the application data is not a single ASN.1 type, but is an octet-
  1100. aligned value, the A0 La xxxx is replaced by 81 La xxxx, where xxxx is
  1101. the value. In this case the length must be definite (unless an
  1102. "unecessary" constructed encoding is used.)
  1103.  
  1104. Identical considerations apply to the other EXTERNALs carried in the
  1105. ACSE pdus.
  1106.  
  1107. 6.2. Successful reply to connection setup
  1108.  
  1109. If the connection attempt is succesful, the following is sent to the
  1110. initiator on a T-DATA.
  1111.  
  1112. This accept contains an item {9} in the presentation-context-result-list
  1113. which is the rejection of some presentation context that was offered.
  1114. This is included to show such a rejection. It is NOT included if this is
  1115. the reply to the connect in 6.1.
  1116.  
  1117.  
  1118. 0E  Ls  {1         - ACCEPT SPDU
  1119. *   Ls  ?
  1120. 05  06  {2         - Connect/Accept Item
  1121. 13  01  01         - Protocol Options
  1122. *   Ls  ?
  1123. 16  01  02         - version number (this shows version 2 only)
  1124.                -- if version 2 was not offered, omit all of {2}
  1125. *   Ls  ?
  1126. .   .   }2         - End Connect/Accept Item
  1127. 14  02  0002       - Session User Requirements (functional units)
  1128.                    - duplex fu only (kernel is automatic)
  1129. *   Ls  ?
  1130. C1  Ls  {3         -- User Data.( tag is C2 if length > 512 )
  1131.   - CPA - P-CONNECT response
  1132. 31  80  {4         - [SET]
  1133.                    -- again, Mode-selector could come at the end
  1134. A0  80  {          -  Mode-selector [0], length=3
  1135. 80  01  01         - normal mode - [0], length=1, value=1
  1136.  
  1137.  
  1138. Expires 11 February 1994                                     [Page 20]
  1139.  
  1140. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  1141.  
  1142.  
  1143. A2  80  {5         - [2] SEQUENCE (unnamed)
  1144. *   La  ?
  1145. A5  80  {6         - [5] P-context-definition-result-list
  1146.                 -- following result items are in the order corresponding
  1147.                 -- to the pctx-definition-list in the connect
  1148.                 -- this example assumes that was ACSE, user, rubbish
  1149.                 -- with rubbish rejected
  1150. 30  80  {7         - [SEQUENCE] result item for acse
  1151. 80  01  00         -- [0] result, value 0 is acceptance
  1152. 81  02  5101       -  [1] accepted transfer syntax name = BER
  1153.                    - note that this has an implicit tag, not 06
  1154. 00  00  }7         - end result item for acse p-ctx
  1155.  
  1156. 30  80  {8         - [SEQUENCE] result item for application-data pctx
  1157. 80  01  00         - [0] value 0 is acceptance
  1158. 81  La  xxxxxx     - [1] oid for transfer syntax, as on defintion list
  1159.                    -- if there were several (groupIII) , the one you
  1160.                    -- liked most
  1161. 00  00  }8         - end result item for app-data p-ctx
  1162.                    -- next SEQUENCE is a rejection of a third pctx
  1163. 30  80  {9         - [SEQUENCE] result item for a rejected pctx
  1164. 80  01  02         -- [0] result, value 2 is provider rejection
  1165. 82  01  00         - [2] reason, value 0 is reason-not-specified
  1166.                    -- there are other reasons, but let's keep it simple
  1167. 00  00  }9         - end result item for rejected pctx
  1168. 00  00  }6         - end p-ctx-def-result-list
  1169. *   La  ?
  1170. 61  80  {10        - [APPLICATION 1] User-data, Fully-encoded
  1171.  
  1172. 30  80  {11        - [SEQUENCE] PDV-list
  1173. 02  01  01         -- [INTEGER] value is pcid for ACSE, as stored from
  1174.                    -- the pctx-definition-list on the P-CONNECT request
  1175. A0  80  {12        - [0] single-ASN1-type
  1176.      - A-ASSOCIATE response APDU - AARE
  1177. 61  80  {13        - [APPLICATION 1] identifies AARE
  1178. *   La  ?
  1179. A1  80  {14        - [1] Application-context
  1180. 06  La  xxxxxx     - [OID] name of application context
  1181.                    - usually the same as on AARQ, can differ
  1182. 00  00  }14
  1183. A2  03  {15        - [2] result
  1184. 02  01  00         - [INTEGER] value 0 means accepted
  1185. 00  00  }15
  1186. A3  80  {16        - [3] result-source-diagnostic
  1187.                    - (curiously, a non-optional field)
  1188. A1  80  {17        - [1] acse-service-user
  1189. 02  01  00         - [INTEGER] value 0 = null ! (why no implicit tag)
  1190. 00  00  }17        - end acse-service-user
  1191. 00  00  }16        - end result source diagnostic
  1192. *   La  ?
  1193.  
  1194.  
  1195. Expires 11 February 1994                                     [Page 21]
  1196.  
  1197. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  1198.  
  1199.  
  1200.          -- the user information field may or may not be required
  1201.          -    (not used for Group I)
  1202. ?BE 80  {20      - [30] IMPLICIT SEQUENCE
  1203. ?08 80  {21      - [EXTERNAL]
  1204.                 -- the transfer-syntax oid is not present this time
  1205. ?02 01  03       - [INTEGER] this is the pcid for the application data
  1206. ?A0 La  xxxx     -- [0] single-ASN1-type (see note at end of 6.1)
  1207. ?00 00  }21      - end of EXTERNAL
  1208.          -- conceivably there may be several EXTERNALS, probably in
  1209.          -- different presentation contexts (different pcids)
  1210. ?00 00  }20      - end of user information field
  1211. 00  00  }13        - end AARE
  1212. 00  00  }12        - end single-asn1-type
  1213. 00  00  }11        - end PDV-list
  1214. 00  00  }10        - end Presn user-data
  1215. 00  00  }5         - end [2] implicit sequence in cpa
  1216. 00  00  }4         - end CPA-type set
  1217. .   .   }3         - end session userdata
  1218. .   .   }1         - end ACCEPT SPDU
  1219.  
  1220.  
  1221. 6.3. Connection rejection
  1222.  
  1223. Refusal is at session-level, but by session user, with no reason given.
  1224. This is a compromise avoiding making unfounded accusations of (session)
  1225. protocol misbehaviour. If the implementation finds it does not like the
  1226. received message, it is not essential to attempt to communicate with the
  1227. partner why, though this may be helpful if the reason is correctly
  1228. identified. (In most cases, a wise implementor will make sure an error
  1229. message goes somewhere or other).
  1230.  
  1231.  
  1232. 0C  03  {1          - REFUSE SPDU
  1233. *   Ls  ?
  1234. 32  01  00          - rejected by SS-user, no reason
  1235. .   .   }1
  1236.  
  1237.  
  1238. The far-end may send interesting things explaining why you are not
  1239. getting interworking. If this is a session reason, the reason code will
  1240. one octet between 81 and 86. If the rejection is higher than session,
  1241. this will be carried on S-REFUSE (so first octet is still 0C) and the
  1242. higher pdu will appear as part of the reason code, which will start with
  1243. 02. (The only remaining code is 01 = user congestion).
  1244.  
  1245. 6.4. Data-phase TSDU
  1246.  
  1247. This is the core of the skinny stack. The lengths shown use a particular
  1248. set of choices for indefinite and definite lengths that means that the
  1249. application data length only affects one field. Making the two earlier
  1250.  
  1251.  
  1252. Expires 11 February 1994                                     [Page 22]
  1253.  
  1254. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  1255.  
  1256.  
  1257. indefinite lengths definite would require more calculation - adding 4
  1258. octets after the application data is assumed to be quicker. This header
  1259. is also designed to be 20 octets long, thus maintaining 4-byte alignment
  1260. between transport and application buffers. Implementations are
  1261. recommended to use this encoding. It is possible to rapidly match
  1262. incoming data against it - if there is no mismatch until the length
  1263. field, the location of the beginning of the data can be determined
  1264. without further analysis.
  1265.  
  1266.  
  1267.  
  1268.           SPDUs
  1269. 01  00  .      - S-GIVE-TOKEN - required by basic concatenation
  1270.                - but no parameters
  1271. 01  00  .      - S-DATA - no parameters - what follows is User
  1272.                - Information, not User Data, so is not included in the
  1273.                - SPDU length fields
  1274.   - P-DATA PPDU - TD (why TD ? Typed-data id TTD !)
  1275. 61  80  {1     - User-data [APPLICATION 1]
  1276. 30  80  {2     - [SEQUENCE] PDV-list
  1277. 02  01  03     - [INTEGER] pcid for application data, P-CONNECT PPDU
  1278.                - remembered by both sides
  1279. 81  83yyyyyy   xxxxxx  --  [1] octet-aligned presentation data value(s)
  1280.               -- length of length (3 octets) then three octets yyyyyy
  1281.               -- for the length of the user data xxxxxx
  1282. 00  00  }2      - End-of-contents for end of PDV-list
  1283. 00  00  }1      - End-of-contents for end of Presentation User-data
  1284.  
  1285.  
  1286. If the application data is in ASN.1, and a single ASN.1 value is being
  1287. sent on the TSDU, the same header can be used except for the tag on the
  1288. presentation data values, which becomes A0 (= [0], constructed).
  1289.  
  1290. If there are multiple data values to be sent, this header can be
  1291. expanded in several ways:
  1292.  
  1293.       a) if there are several ASN.1 values from the same presentation
  1294.       context, they can be concatenated and treated as an octet-aligned
  1295.       value (using the header as shown above, with tag 81 (or A1 - I
  1296.       think its primitive) or  each ASN.1 value can be an item (tagged
  1297.       A0), one after the other
  1298.  
  1299.       b) if the data values are from different presentation contexts
  1300.       (group IV), each is in its own {2} group within the {1}.
  1301.  
  1302. On receipt, for the simple octet-aligned case, the data value may itself
  1303. have a constructed encoding - this will make the tag A1, and it will
  1304. contain elements each tagged 04 (OCTET STRING). According to CULR-1,
  1305. these elements are primitive (otherwise they would be 24 of course).
  1306.  
  1307.  
  1308.  
  1309. Expires 11 February 1994                                     [Page 23]
  1310.  
  1311. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  1312.  
  1313.  
  1314. 6.5. Closedown  - release request
  1315.  
  1316. When all is done, and you want to close down gracefully, send this on T-
  1317. DATA.
  1318.  
  1319.     - FINISH SPDU
  1320. 09  10  {1         - 9 identifies FINISH
  1321. *   Ls  ?          - No Transport Disconnect item
  1322.                    - default is release Transport-connection
  1323. C1  0E  {2         - User data (code 193)
  1324.     - P-RELEASE req/ind PPDU (has no name)
  1325. 61  80  {3         - [APPLICATION 1], user data, fully-encoded
  1326. 30  80  {4         - [SEQUENCE] PDV-list
  1327. 02  01  01         -- pcid for ACSE, remembered from setup
  1328. A0  80  {5         - [0] single asn.1-type
  1329.     - A-RELEASE request APDU - RLRQ
  1330. 62  80  {6         - [APPLICATION 2] identifies RLRQ
  1331. 80  01  00         - [0] reason, value 0 means normal
  1332. *   La  ?
  1333.          -- the user information field may or may not be required
  1334.          - ( not required for Group I)
  1335. ?BE 80  {7       - [30] IMPLICIT SEQUENCE
  1336. ?08 80  {8       - [EXTERNAL]
  1337.                  -- the transfer-syntax oid is not present this time
  1338. ?02 01  03       - [INTEGER] this is the pcid for the application data
  1339. ?A0 La  xxxxx    -- [0] single-ASN.1-type application data
  1340.                  -- (see note at end of 6.1)
  1341. ?00 00  }8       - end of EXTERNAL
  1342.          -- conceivably there may be several EXTERNALS, probably in
  1343.          -- different presentation contexts (different pcids)
  1344. ?00 00  }7       - end of user information field
  1345. 00  00  }6         - end of RLRQ
  1346. 00  00  }5         - end of single asn.1-type
  1347. 00  00  }4         - end of PDV-list
  1348. 00  00  }3         - end of Presentation User-data
  1349. .   .   }2         - end of session user data
  1350. .   .   }1         - end of FINISH SPDU
  1351.  
  1352.  
  1353.  
  1354. 6.6. Closedown - release response
  1355.  
  1356. On receiving a FINISH, you send this to tell the other end it is all
  1357. over
  1358.  
  1359.     - Session DISCONNECT SPDU
  1360. 0A  10  {1         - SI=10, DISCONNECT
  1361. C1  0E  {2         - User data (tag = C2 if length >512)
  1362.     - P-RELEASE rsp PPDU
  1363. 61  80  {3         - [APPLICATION 1], user data, fully-encoded
  1364.  
  1365.  
  1366. Expires 11 February 1994                                     [Page 24]
  1367.  
  1368. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  1369.  
  1370.  
  1371. 30  80  {4         - [SEQUENCE] PDV-list
  1372. 02  01  01         -- [INTEGER] pcid for ACSE, remembered from setup
  1373. A0  80  {5         - [0] single asn.1-type
  1374.     - A-RELEASE response APDU - RLRE
  1375. 63  80  {6         - [APPLICATION 3] identifies RLRE
  1376. 80  01  00         - [0] reason, value 0 means normal
  1377. *   La  ?
  1378.          -- the user information field may or may not be required
  1379.          - (not required for Group I)
  1380. ?BE 80  {7       - [30] IMPLICIT SEQUENCE
  1381. ?08 80  {8       - [EXTERNAL]
  1382.                 -- the transfer-syntax oid is not present this time
  1383. ?02 01  03       - [INTEGER] this is the pcid for the application data
  1384. ?A0 La  xxxxx    -- [0] single-ASN.1-type application data
  1385.                  -- (see note at end of 6.1)
  1386. ?00 00  }8       - end of EXTERNAL
  1387.          -- conceivably there may be several EXTERNALS, probably in
  1388.          -- different presentation contexts (different pcids)
  1389. ?00 00  }7       - end of user information field
  1390. 00  00  }6         - end of RLRE
  1391. 00  00  }5         - end of single asn.1-type
  1392. 00  00  }4         - end of PDV-list
  1393. 00  00  }3         - end of Presentation userdata
  1394. .   .   }2         - end of session userdata
  1395. .   .   }1         - end of DISCONNECT SPDU
  1396.  
  1397. 6.7. Deliberate abort
  1398.  
  1399. It is not clear whether this is any use - just clearing the Transport
  1400. connection will be more effective. It goes on T-DATA, but asks for the
  1401. far-side to close the T-connection.
  1402.  
  1403.     - Session ABORT SPDU
  1404. 19  15  {1      - SI of 25 is ABORT
  1405. 11  01  03      - Transport Disconnect PV, code 17
  1406.                 --  value = '...00011'b means please
  1407.                 -- release T-conn, user abort
  1408. *   Ls  ?
  1409. C1  11  {2      - Session User Data
  1410.     - P-U-ABORT PPDU - ARU
  1411. A0  80  {3      - [0] implicit sequence for normal mode
  1412. A0  80  {4      - [0] presentation-context-identifier-list
  1413. 30  80  {5      - [SEQUENCE]
  1414. 02  01  01      - [INTEGER]pcid for ACSE
  1415. 06  02  5101    - [OID] for acse transfer syntax = BER
  1416. 00  00  }5
  1417.          -- there will be one {6} group for each application
  1418.          -- presentation context that is used in this message
  1419.          -- if there is no user data, the {6} group can be
  1420.          -- omitted
  1421.  
  1422.  
  1423. Expires 11 February 1994                                     [Page 25]
  1424.  
  1425. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  1426.  
  1427.  
  1428. 30  80  {6
  1429. 02  01  03      - [INTEGER] pcid for application data
  1430. 06  La  xxxxxx  - [OID] transfer syntax for application data
  1431. 00  00  }6
  1432. 00  00  }4      - end of presentation-context-identifier-list
  1433. 61  80  {7      - [APPLICATION 1], user data, fully-encoded
  1434. 30  80  {8      - [SEQUENCE] PDV-list
  1435. 02  01  01      - [INTEGER] pcid for ACSE as on CP PPDU
  1436. A0  05  {9      - [0] single asn.1-type
  1437.     - A-ABORT APDU - ABRT
  1438. 64  80  {10     - [APPLICATION 4] identifies ABRT
  1439. 80  01  01      -  [0] value 1 is acse-service-provider
  1440.          -- the user information field may or may not be required
  1441. ?BE 80  {11      - [30] IMPLICIT SEQUENCE
  1442. ?08 80  {12      - [EXTERNAL]
  1443.                 -- the transfer-syntax oid is not present this time
  1444.                 -- (according to CULR-1)
  1445. ?02 01  03       - [INTEGER] this is the pcid for the application data
  1446. ?A0 La  xxxxx    -- [0] single-ASN.1-type application data
  1447.                  -- (see note at end of 6.1)
  1448. ?00 00  }12      - end of EXTERNAL
  1449.          -- conceivably there may be several EXTERNALS, probably in
  1450.          -- different presentation contexts (different pcids)
  1451. ?00 00  }11      - end of user information field
  1452. 00  00  }10     - end of ABRT
  1453. 00  00  }9      - end of single asn.1-type
  1454. 00  00  }8      - end of PDV-list
  1455. 00  00  }7      - end of Presentation user-data
  1456. 00  00  }3      - end of ARU-PPDU
  1457. .   .   }2      - end of session user-data
  1458. .   .   }1      - end of ABORT SPDU
  1459.  
  1460.  
  1461. 6.8. Provider abort
  1462.  
  1463. Generated when an internal error occurs (i.e. something has gone mildly
  1464. (?) wrong in the cookbook implementation). Rather than accuse anyone of
  1465. protocol errors, we just abort at session.
  1466.  
  1467.           ABORT SPDU
  1468. 19  03  {1         - SI=25 = ABORT SPDU
  1469. 11  01  09         - Transport Disconnect PV, code 17
  1470.                  -- value = '...01001'b  release T-conn
  1471.                  --  no reason
  1472. *   Ls  ?
  1473. .   .   }1
  1474.  
  1475.  
  1476.  
  1477.  
  1478.  
  1479.  
  1480. Expires 11 February 1994                                     [Page 26]
  1481.  
  1482. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  1483.  
  1484.  
  1485. 6.9. Abort accept
  1486.  
  1487. If a Session abort (of any kind) is sent, it is possible that the far-
  1488. end will send back an abort accept. If this happens, disconnect the
  1489. transport. (The abort messages above do not propose that the transport
  1490. connection be reused, and in this case, an abort accept is just the far-
  1491. end passing the transport-disconnect initiative back.) This session
  1492. message need never be sent - just disconnect transport on receiving an
  1493. abort.
  1494.  
  1495.           ABORT ACCEPT SPDU
  1496. 1A  00  .         - SI=26 = ABORT ACCEPT SPDU, no parameters
  1497.  
  1498.  
  1499. 7. References
  1500.  
  1501. [CULR-1] Working draft 13 of Common upper layer requirements - Part 1 :
  1502. basic connection-oriented requirements; EWOS. (A later draft will be
  1503. proposed as ISP 11188/1)
  1504.  
  1505. [CULR-3] Draft of Common Upper-layer requirements - Part 3: Minimal OSI
  1506. upper layers facilities (A later draft will be proposed as ISP 11188/3)
  1507.  
  1508. [ISO8072] Information processing systems - Open Systems Interconnection
  1509. - Transport service definition; ISO, 1986.
  1510.  
  1511. [ISO8073] Information processing systems - Open Systems Interconnection
  1512. - Transport protocol specification; ISO, 1986.
  1513.  
  1514. [ISO8326] Information processing systems - Open Systems Interconnection
  1515. - Basic connection oriented session service definition; ISO, 1987. (or
  1516. review copy of revised text = ISO/IEC JTC1/SC21 N4657, April 1990)
  1517.  
  1518. [ISO8327] Information processing systems - Open Systems Interconnection
  1519. - Basic connection oriented session protocol specification; ISO, 1987.
  1520. (or review copy of revised text = ISO/IEC JTC1/SC21 N4656, April 1990)
  1521.  
  1522. [ISO8649] Information processing systems - Open Systems Interconnection
  1523. - Service definition for the Association Control Service Element; ISO,
  1524. 1989
  1525.  
  1526. [ISO8650] Information processing systems - Open Systems Interconnection
  1527. - Protocol specification for the Association Control Service Element;
  1528. ISO, 1989
  1529.  
  1530. [ISO8822] Information processing systems - Open Systems Interconnection
  1531. - Connection-oriented presentation service definition; ISO, 1989
  1532.  
  1533. [ISO8823] Information processing systems - Open Systems Interconnection
  1534. - Connection-oriented presentation protocol specification; ISO, 1989
  1535.  
  1536.  
  1537. Expires 11 February 1994                                     [Page 27]
  1538.  
  1539. INTERNET DRAFT      ThinOSI upper-layers cookbook         August, 1993
  1540.  
  1541.  
  1542. [ISO8824] Information technology - Open Systems Interconnection -
  1543. Specification of Abstract Syntax Notation One (ASN.1), ISO/IEC 1990
  1544.  
  1545. [ISO8825] Information technology - Open Systems Interconnection -
  1546. Specification of Basic Encoding Rules for Abstract Syntax Notation One,
  1547. ISO/IEC 1990
  1548.  
  1549. [RFC1006] ISO transport services on top of the TCP; Rose M.T, Cass D.E,
  1550. 1987
  1551.  
  1552. [ISO9594] Information technology - Open Systems Interconnection - The
  1553. Directory; ISO/IEC, 1990
  1554.  
  1555. [RFC 1274] The Internet and Cosine Schema; Kille, S.H., 1992
  1556.  
  1557.  
  1558.  
  1559.  
  1560. 8. Other notes
  1561.  
  1562. The Session, Presentation and ACSE standards have been the subject of
  1563. considerable amendment since their first publication. The only one that
  1564. is significant to this cookbook is Session addendum 2, which specifies
  1565. session version 2 and unlimited user data. There are plans to produce
  1566. new editions of these standards, incorporating all the amendments,
  1567. published in early 1994.
  1568.  
  1569. The coding choices made in the cookbook are (nearly) those made by the
  1570. "Canonical Encoding Rules", which are a form of Basic Encoding Rules
  1571. with no optionality, specified in an amendment to ISO/IEC 8825
  1572. (currently a new part of 8825 at Draft International Standard status,
  1573. but likely to be folded into a new edition of 8825). A defect report has
  1574. been proposed against Presentation and ACSE, suggesting that a note to
  1575. the protocol specifications recommend use of the canonical encoding
  1576. options when sending, and then optimising for this on receipt.
  1577.  
  1578.  
  1579. 9. Author's Address
  1580.  
  1581. Peter Furniss
  1582. Peter Furniss Consultants
  1583. 58 Alexandra Crescent
  1584. Bromley, Kent BR1 4EX
  1585. UK
  1586.  
  1587. Phone & fax +44 81 313 1833
  1588.  
  1589. Email: P.Furniss@ulcc.ac.uk
  1590.  
  1591.  
  1592.  
  1593.  
  1594. Expires 11 February 1994                                     [Page 28]
  1595.  
  1596.